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ABSTRACT 

The complex and diverse nature of the pay- 
load operations to be performed on the 
Space Station requires a robust and flexible 
planning approach, and the proper software 
tools to support that approach. To date, the 
planning software for most manned opera- 
tions in space has been utilized in a central- 
ized planning environment. Centralized 
planning is characterized by the following: 
performed by a small team of people, per- 
formed at a single location, and performed 
using single-user planning systems. This ap- 
proach, while valid for short duration flights, 
is not conducive to the long duration and 
highly distributed payload operations envi- 
ronment of the Space Station. The Payload 
Planning System (PPS) is being designed 
specifically to support the planning needs of 
the large number of geographically distrib- 
uted users of the Space Station. This paper 
provides a general description of the distrib- 
uted planning architecture that PPS must 
support and describes the concepts proposed 
for making PPS available to the Space Sta- 
tion payload user community. 


1. INTRODUCTION 

The key to the success of any tool is not how 
well it performs its functions, but whether it 
performs the right functions well. There are 
a number of existing planning tools which 
have been used to support centralized plan- 
ning; however, these tools were not de- 
signed with distributed planning in mind. 
The tools needed for Space Station distrib- 
uted planning must have the following char- 
acteristics: 

• Graphical interface which is easy to 
learn and use 

• Ability to run on commonly available 
hardware/software platforms 

• Powerful data managing and reporting 
mechanisms 

• Functions which allow the scheduling 
problem to be subdivided and distributed 
among the users of the Space Station 

• Scheduling and modeling algorithms 
which conceal the complexity of the un- 
derlying Space Station resources. 



These tools will allow each user group to 
participate in the planning for their experi- 
ments without requiring detailed knowledge 
of the Space Station systems required to 
support those operations. This paper fo- 
cuses on the software distribution aspects 
necessary to provide this capability. 

2. PLANNING CONCEPT 

Because of the diverse and dynamic payload 
complement, no one organization will have 
the knowledge and expertise required to per- 
form detailed planning for all payloads on 
the Space Station. Since the knowledge and 
expertise is spread across a number of con- 
trol centers and payload user facilities 
throughout the world, it makes sense to dis- 
tribute the planning as well. While there are 
many possible ways of supporting distrib- 
uted planning, the hierarchical distribution 
of resources appears to be the approach 
which is best suited for Space Station pay- 
load operations planning. 

Figure 2-1 provides an overview of the ar- 
chitecture which supports this approach. 
This architecture consists of various levels 
of planning, where the functions of a par- 
ticular level are performed by one or more 
organizations. Rather than expressing this 
concept using Space Station specific termi- 
nology, the concept is described in general 
terms which can be applied to other distrib- 
uted planning problems. 


resents the individual users of the Space Sta- 
- tion. These individuals have specific pay- 
load operations which need to be scheduled, 
and are in competition with one another for 
the limited resources available to support 
those operations. The ILPF represents the 
organization or organizations which serve as 
the interface between the ULPF and the 
LLPF. In most cases, the ILPF represents 
the sponsoring organization or country of 
the users. In cases where there is no ILPF 
organization, the LLPF interfaces directly 
with the ULPF. There may be multiple ILPF 
levels, where one ILPF organization exists 
to serve the ILPF organizations which fall 
under its authority. Refer to Figure 1 for a 
pictorial representation of this architecture 
and the relationships between the ULPF, 
ILPF, and LLPF organizations. 
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Figure 2-1 Architecture 


In general, there are three basic levels of 
planning: 1) Upper Level Planning Function 
(ULPF), 2) Intermediate Level Planning 
Function (ILPF), and 3) Lower Level Plan- 
ning Function (LLPF). The ULPF repre- 
sents the controlling authority and is ulti- 
mately responsible for the integrated plan of 
payload operations. There is only one ULPF, 
although there may be many organizations 
which support its functions. The LLPF rep- 


The basic premise of this concept is that re- 
sources are distributed in a manner which al- 
lows for concurrent and independent plan- 
ning at each level in the architecture. 
Requests for resources are passed from the 
LLPF upwards through the ILPF level(s) to 
the ULPF. The ULPF, taking into account 
all of the requests for resources, distributes 
the available resources to the ILPF. Each 
ILPF then distributes its resources to the 
level below it, either another ILPF level or 










the LLPF. At the LLPF level, the users de- 
velop plans within their resource distribu- 
tions and pass those plans back up through 
the path to the ULPF. Each level, by having 
visibility into all of the requests for re- 
sources from the levels below, can ensure a 
distribution of resources which best satisfies 
the needs of its users. Conversely, since 
each level of the planning hierarchy is iso- 
lated from all other peer levels, planning can 
be accomplished without regard for work 
being done at other planning centers. This 
independence allows the total mission plan- 
ning problem to be distributed across many 
planners, which decreases the amount of 
wall-clock time required to develop sched- 
ules. The flow of this information from one 
level to the next is depicted in Figure 2-1. 

3. SYSTEM DISTRIBUTION 

There are two principal options available for 
distributing a computing problem among 
several processing sites. The first is to pass 
the partial and evolving solution between 
sites until everyone is satisfied with the re- 
sults. In general this tends to serialize the 
process and can require a large amount of 
information to be explicitly transferred be- 
tween sites. The second option is to central- 
ize the storage of the information and ar- 
range it in such a way that many users can 
work on their data simultaneously without 
interfering with other users’ work. The key 
problem here is in making all the informa- 
tion readily available to the appropriate us- 
ers. The architecture that implements this 
solution is called "client-server". The fol- 
lowing sections provide an overview of 
client-server systems, a description of the 
PPS client-server design, and the different 
ways this design can be implemented by the 
various users of the payload planning sys- 
tem. 

3.1 CLIENT-SERVER OVERVIEW 

A client-server architecture provides for re- 


source sharing between systems. The server 
-in such an architecture provides services to 
other systems. The client is the system 
which requests the services. There are two 
immediate advantages of this architecture. 
Since there is one server for all the data, it 
can apply centralized data managing tech- 
niques such as a relational database manage- 
ment system or a file management system to 
the data under its control. These solutions 
are readily available and provide substantial 
control over and protection for shared data. 
The second advantage is the independence 
of the client from the server. Any hard- 
ware/software combination which can effec- 
tively interface with the server can help 
process data in the client-server system. As 
shown in Figure 3.1-1, three different hard- 
ware/software platforms are connected as 
clients to the server, which provides them 
each with a view of the database at the top 
of the figure. This allows substantial flexi- 
bility to the users of this system, since they 
can each use hardware they own and are fa- 
miliar with and which has been sized prop- 
erly for their portion of the problem. 

In developing a client-server system the fol- 
lowing items should be kept in mind: 

• The system should be sized to support 
the anticipated number of users 

• The system should be sized to manage 
the appropriate volume of data 

• The system should not be sensitive to the 
addition or removal of clients. 

The operation of a client-server system is 
also heavily dependent on the network 
which transfers information between the cli- 
ents and the server. A server can generally 
support several methods for network com- 
munication with clients, helping to further 
isolate the hardware dependencies from the 
information processing. 
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Figure 3.1-1: Client-Server Overview 


3.2 PPS CLIENT-SERVER DESIGN 

PPS is not a single application, but a collec- 
tion of applications which together comprise 
the entire system. These applications work 
together to solve the planning problem 
through the sharing of data. Figure 3.2-1 
provides an overview of the PPS architec- 
ture. The external systems shown on the fig- 
ure represent those systems with which PPS 
must exchange data. These external system 
interfaces are subject to change as PPS ma- 
tures and as new systems come into exis- 
tence. 

Within the PPS network, the PPS applica- 
tion may be found on any number of hosts. 
Each of these applications interacts with the 
database through a common data server. In 
this manner, the majority of the processing 
workload is shifted from the server to the in- 


dividual hosts on which the PPS application 
is being executed. Each host on which the 
PPS application resides can support a num- 
ber of simultaneous users. The size and 
number of hosts required to support the 
planning process will be determined by the 
number and types of users the host must 
support. 



Figure 3.2-1: PPS Architecture 






3.3 PPS CLIENT-SERVER 
IMPLEMENTATION 

The PPS client-server design is very extensi- 
ble, and provides individual users as well as 
groups of users with several options for util- 
izing the system. The following section pro- 
vides a sampling of the ways in which mem- 
bers of the user’s community can fit into the 
client-server environment supported by 
PPS. 

3.3.1 Remote User Access 
The remote user access implementation pro- 
vides a low cost method through which indi- 
vidual users can be provided with access to 
PPS. In this implementation, the user pro- 
vides an x-windows terminal. The PPS ap- 
plication resides and executes on a Space 
Station program provided host. Refer to Fig- 
ure 3.3. 1-1 for a graphical representation of 
this option. The x-windows terminal merely 


PPS PPS 

PPS data application 

DATABASE SERVER HOST 



X-WINDOWS TERMINAL 


Figure 3.3. 1-1: Remote User Access 

serves as the display device for the PPS ap- 
plication. While this is a fairly low cost op- 
tion for individual users, it is not without 
drawbacks. The program provided host may 
be required to serve large numbers of users 
which ultimately will affect response time. 


The number of users that can be supported 
_ by this implementation will be defined to a 
large extent by the size of the host provided 
by the program. The response time will also 
be affected by the type and throughput of the 
networks being utilized by the user. 

3.3.2 User Provided Host 

The user provided host implementation is 
more costly to the user; however, this option 
can provide significantly better response 
time. The user in this case not only provides 
the display device, but also provides a host 
for the PPS application. This eliminates 
competition for processing time with other 
PPS users. Communications is still a con- 
cern, as the PPS application must request 
data over the network from the PPS data 
server. A drawback to this implementation is 
that the user is responsible for the systems 
management and maintenance of the local 
host. Refer to Figure 3.3.2- 1 for a graphical 
representation of this option. 
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Figure 3.3.2- 1: User Provided Host 

3.3.3 Facility Provided Host 

The facility provided host implementation 



may provide the most cost effective and effi- 
cient option for user access to PPS. A facil- 
ity can be any organization which sponsors 
or supports a number of users. In this imple- 
mentation, the program provides the PPS da- 
tabase and the database server, the facility 
provides the PPS application host, and the 
user provides the x-windows terminal. In 
this manner, the costs associated with pur- 
chasing and maintaining the PPS application 
host can be spread across a number of users. 
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Figure 3.3.3- 1: Facility Provided Host 

The host can be sized specifically for its in- 
tended users. Response time for each user 
should be adequate if the ratio of users to 
host size is appropriate. Refer to Figure 
3.3.3- 1 for a graphical representation of this 


option. 


4. SUMMARY 

[to be rewritten] The general approach to 
Space Station distributed mission planning 
was discussed, along with generic client- 
server architecture and specific configura- 
tion options for PPS. Every user of the Pay- 
load Planning System will have the option to 
configure his planning system assets to best 
suit his requirements for cost, availability, 
redundancy, and performance. Users who 
form cooperative planning facilities will re- 
alize the most effective combination of these 
attributes. 
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